Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 
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Until  recently,  most  of  those  involved  in  research, 
development,  and  operation  of  secure  computing  sys¬ 
tems  have  been  either  autodidacts  or  individually 
mentored  by  people  already  working  in  the  Held.  To¬ 
day’s  practitioners  learned  computer  security  as  it  was 
growing  up  around  them.  Security  concerns  have  cre¬ 
ated  an  increased  demand  for  computer  security  pro¬ 
fessionals.  Students  want  to  learn  about,  computer 
security  and  potential  employers  want  graduates  who 
can  go  to  work  solving  their  problems. 

We,  the  members  of  the  computer  security  commu¬ 
nity,  must  be  responsible  for  producing  the  next  gen¬ 
eration  of  computer  security  experts.  The  objective 
of  this  panel  is  to  present  and  discuss  the  opinions  of 
people  who  hire  computer  science  graduates  to  work 
on  computer  security  problems.  Thus,  the  panel  seeks 
not  to  have  computer  security  educators  tell  the  au¬ 
dience  what  they  are.  teaching,  but  to  have  employers 
tell  us  what  needs  to  be  taught. 

Questions  to  be  addressed  include: 

•  What  should  students  be  taught  to  equip  them 
to  become  productive  members  of  the  computer 
security  community^ 

•  Can  one  emerge  from  an  undergraduate  or  grad¬ 
uate  program  ready  to  go  to  work  as  a  computer 
security  specialist? 

•  How  up-to-the-minute  should  graduates  be  with 
respect  to  current  technology? 

•  Is  there  a  fundamental  body  of  knowledge  which 
should  be  taught  universally?  Is  it  based  on  re¬ 
sults  from  the  literature,  requirements  and  crite¬ 
ria.,  or  is  it.  threat,  driven? 

•  Wha.t.  suggestions  for  material  to  be  included  in 
textbooks  can  industry  provide? 

•  Should  students  of  computer  security  learn  wha.t. 
“hackers”  do  and  try  out.  “controlled  hacking”  as 
part,  of  their  education? 

•  How  much  should  students  learn  about,  specific 
systems  such  as  UNIX  or  commercially  available 
PC  operating  systems? 

•  Computer  security  touches  on  a.  broad  range 
of  topics  in  computer  science  and  engineering. 
Should  students  know  a.  little  about,  a.  lot.  of  areas 
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Figure  1:  Annual  Computer  Emergency  Response 
Team  Advisories 
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Figure  2:  Growth  of  World  Wide  Web  Sites 


or  should  their  education  be  focussed  in  selected 
areas? 

•  Should  graduates  be  able  So  differentiate  real  se¬ 
curity  from  snake  oil?  How  can  this  be  taught? 

•  Besides  $$$,  how  can  industry  help  with  computer 
security  education? 

Two  quite  different,  approaches  to  computer  security 
education  appear  emerge  from  these  questions. 

First,  security  in  computer  systems  can  be  treated 
as  an  ad  hoc  set.  of  functions  which  are  modified  as 
vulnerabilities  are  identified.  Examination  of  Figure  1 
shows  that,  following  an  initial  steep  rise,  the  number 
of  Computer  Emergency  Response  Team  (CERT)  Ad¬ 
visories  per  year  has  remained  reasonably  constant.  [3]. 
Yet.  as  Figure  2  illustrates  for  the  World  Wide  Web, 
interconnectivity  continues  t.o  grow  [5].  Consequently 
we  will  need  a.  few  people  to  find  system  flaws  and  de^ 
scribe  the  fixes,  and  a.  much  larger  number  of  people 
to  plug  the  holes  in  all  of  the  individual  systems.  To 
be  proficient,  at.  identifying  and  repairing  system  vul¬ 
nerabilities,  students  will  need  to  become  well  versed 
in  the  intricacies  of  specific  system  implementations. 


Some  classroom  exercises  can  focus  on  case  studies 
of  vulnerabilities  and  flaws  in  existing  systems  that 
have  been  exploited  by  misfeasors  and  what  security 
experts  did  to  thwart  future  use  of  those  flaws.  Simu¬ 
lations  allowing  students  test  penetrations  and  reme¬ 
dies  could  be  useful.  Students  could  study  operating 
systems  and  applications  to  learn  how  flawed  systems 
have  been  constructed,  choices  that  lead  to  the  intro¬ 
duction  of  flaws,  and  where  security  blunders  often 
occur.  Software  engineering  could  contrast  academic 
concepts  with  the  less  than  ideal  disciplines  used  in 
the  Held.  Because  the  real  systems  being  used  in  gov¬ 
ernment  and  commerce  are  proprietary,  schools  would 
need  to  establish  non-disclosure  agreements  with  ven¬ 
dors  so  that  thorough  investigations  would  be  possible. 
Research  could  result  in  papers  analyzing  specific  in¬ 
cidents  of  flaw  exploitation  such  as  the  Internet  Worm 
of  1988  [10];  categorization  of  flaws  in  various  systems, 
e.g.  [7];  identification  of  flaws  in  specific  products,  e.g. 
[4];  and  techniques  for  remedying  these  flaws. 

The  second  approach  is  to  build  security  into  our 
systems  ab  initio  using  an  engineering-oriented  ap¬ 
proach  based  on  fundamental  principles.  Here  it  is 
assumed  that  one  cannot  know  a  posteriori  whether 
a  system  is  secure.  Students  would  learn  fundamen¬ 
tals  such  as  the  Reference  Monitor  Concept  [1]  and 
the  safety  problem  [6].  They  would  learn  how  se¬ 
curity  policies  and  their  mathematical  formulations, 
e.g.  [2,  8]  provide  a  blueprint  for  constructing  a  sys¬ 
tem  intended  to  provide  policy  enforcement.  Students 
could  start  by  seeing  how  systems  with  assured  se¬ 
curity  properties  were  built  in  the  past,  e.g.,  [9]  and 
[11].  Tracing  the  application  and  extension  of  basic 
security  principles  through  the  evolving  technology  to 
the  hottest  developments  emerging  from  industry,  the 
educational  program  would  prepare  students  to  un¬ 
derstand  how  these  concepts  might  be  applied  in  the 
future.  Needless  to  say  hefty  doses  of  software  engi¬ 
neering,  operating  systems,  as  well  as  a  rigorous  set  of 
core  computer  science  courses  would  be  needed. 

Many  topics  are  likely  to  be  common  to  both  ap¬ 
proaches:  an  introduction  to  the  concepts  underly¬ 
ing  modern  cryptography;  the  need  for  sound  cryp¬ 
tographic  protocols,  and  the  challenges  of  key  man¬ 
agement  and  key  distribution;  why  auditing  as  well  as 
identification  and  authentication  are  needed  and  how 
they  are  accomplished;  the  need  for  physical  and  per¬ 
sonnel  security;  etc.  The  use  of  newly  evolving  tools 
and  methods  from  both  academic  programs  and  in¬ 
dustry  can  provide  interesting  challenges  to  students. 

The  panelists  come  from  different  sections  of  the 
computer  security  community.  Leslie  Chalmers  repre¬ 
sents  Wells  Fargo  Bank,  an  enterprise  where  lack  of 
security  controls  could  have  disastrous  consequences 
in  terms  of  financial  impact  and  loss  of  consumer  con¬ 
fidence.  As  Deputy  Director  of  the  National  Computer 
Security  Center,  Stephen  F.  Barnett  represents  an  or¬ 
ganization  well  known  for  its  contributions  to  com¬ 
puter  security  education,  research  and  development. 
Jim  Schindler  is  from  Hewlett  Packard  where  he  man¬ 
ages  the  development  of  new  security  products  and 
brings  to  the  panel  the  perspective  of  an  enterprise 
attempting  to  meet  marketplace  demands  for  infinite 


MIPS,  perfect  security,  and  zero  cost.  The  next  pan¬ 
elist  is  Roger  Schell,  of  Novell,  Inc.,  who  has  been 
an  educator,  worked  in  the  Department  of  Defense, 
and  now  leads  a  group  developing  new  commercial  se¬ 
curity  technology.  Finally,  Karl  Levitt,  Professor  of 
Computer  Science  at  the  University  of  California  at 
Davis,  will  serve  on  the  panel  as  a  representative  of 
the  educational  community. 
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